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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The present document describes the Service and Capability Requirements of TISPAN NGN Release 2. 



Introduction 



The present document specifies the requirements that need to be fulfilled by NGN technical specifications to provide 
services in an NGN. 

The present document considers two service sets: IP Multimedia Services and PSTN/ISDN Emulation services. Each of 
these service sets has its own clause, which is further divided into clauses providing clear and precise requirements for 
each of these two service sets. Further clauses provide generic network requirements to support service deployment and 
interoperability. 

The present document provides generic requirements on networks from a service point of view. Specific details of 
individual services and capabilities are provided in other documents. 
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Scope 



The present document specifies network requirements in terms of service-related capabilities for TISPAN NGN. The 
present document places requirements for all TISPAN NGN subsystems. 

The present document provides generic requirements for services and interoperability in TISPAN NGN in terms of the 
capabilities for a network or networks. 

Requirements on service-related subsystems provide sufficient details for architecture, networking requirements and 
protocols to be specified. Requirements on service independent subsystems are contained within the service-related 
subsystem requirements. 

Specific service requirements may be contained in other documents, as identified in the present document, and by other 
documents referencing the present document. 

The present document does not define services, only capabilities and requirements. The present document does not 
place requirements on terminals or other customer-owned equipment. The present document specifies the 
service-related requirements that are used to determine the network architecture, requirements and control protocols 
for a network interface to a customer environment. 

NOTE: The present document uses the term "NGN" only in the context of TISPAN. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 122 340: "Universal Mobile Telecommunications System (UMTS); IP Multimedia 

Subsystem (IMS) messaging; Stage 1 (3GPP TS 22.340)". 

[2] ETSI TS 122 141: "Universal Mobile Telecommunications System (UMTS); Presence service; 

Stage 1 (3GPP TS 22.141 version 7.0.0 Release 7)". 
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[3] ETSI TS 102 424: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Requirements of the NGN network to support Emergency 
Communication from Citizen to Authority". 

[4] ETSI TS 188 003: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); OSS requirements; OSS definition of requirements and 
priorities for further network management specifications for NGN". 

[5] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[6] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[7] ETSI TS 187 001: " Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); NGN SECurity (SEC); Requirements". 

[8] ETSI TS 122 1 15: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Service aspects; Charging and billing (3GPP TS 22.1 15)". 

[9] ETSI TS 122 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Service requirements for the Internet Protocol (IP) 
multimedia core network subsystem (IMS); Stage 1 (3GPP TS 22.228 version 7.3.0 Release 7)". 

[10] ITU-T Recommendation G.722: "7 kHz Audio Coding within 64 Kbit/s". 

[11] ETSI TS 126 171: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Speech codec speech processing functions; Adaptive 
Multi-Rate - Wideband (AMR-WB) speech codec; General description 
(3GPPTS 26.171 Release 7)". 

[12] ITU-T Recommendation G.729.1: G.729 based Embedded Variable bit-rate coder: An 8-32 Kbit/s 

scalable wideband coder bitstream interoperable with G.729. 

[13] 3GPP2 C.S0014-C (Version 1.0): "Software Distribution for Enhanced Variable Rate 2 Codec 

(EVRC), Speech Service Options 3, 68, and 3 70, Specification", December 2006 
(C.R0014-Cvl.O ). 

[14] ETSI TS 122 101: "Universal Mobile Telecommunications System (UMTS); Service aspects; 

Sei-vice principles (3GPP TS 22.101 Release 7)". 

[15] ETSITS 181 018: " Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Requirements for QoS in a NGN". 

2.2 Informative references 

[16] ETSI TR 180 000: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Terminology". 

[17] ETSI TS 187 005: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Lawful Interception; Lawful interception functional 
entities, information flow and reference points". 

[18] IETF RFC 2486: "The Network Access Identifier" . 

[19] ETSI TS 122 173: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); IP Multimedia Core Network Subsystem (IMS) 
Multimedia Telephony Service and supplementary services; Stage 1 (3GPP TS 22.173 
version 7.4.0 )". 

[20] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 
(3GPP TS 23.228 version 7.9.0 Release 7)". 
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[21] ETSI TS 123 003: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Numbering, addressing and identification 
(3GPP TS 23.003 version 7.5.0 Release 7)". 

[22] ETSI TS 181 002: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Multimedia Telephony with PSTN/ISDN simulation services". 

[23] ETSI TS 181 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Videotelephony over NGN; Stage 1 service description". 

[24] ETSI ETS 300 059: "Integrated Services Digital Network (ISDN); Subaddressing (SUB) 

supplementary service; Service Description". 

[25] ETSI ETS 300 284: "Integrated Services Digital Network (ISDN); User-to-User Signalling (UUS) 

supplementary service; Service description". 

[26] ETSI TR 181 015: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Requirements for Customized Originating and Terminating 
Multimedia Information Presentation (COMIP/CTMIP) and Customized Originating and 
Terminating Multimedia Information Filtering (COMIF/CTMIF) Requirements Analysis". 

[27] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies". 

[28] ITU-T Recommendation H.263: "Video coding for low bit rate communication". 

[29] ITU-T Recommendation H.264: "Advanced video coding for generic audiovisual services". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the definitions given in TS 122 228 [9] and TR 180 000 [16] apply: 

• IP multimedia application (see TS 122 228 [9]); 

• IP multimedia service (see TS 122 228 [9]); 

• IP multimedia session: (see TS 122 228 [9]); 

• IP Multimedia Core Network Subsystem (IM CN Subsystem) (see TS 122 228 [9]); 

• nomadism (see TR 180 000 [16]); 

• portability (see TR 180 000 [16]). 

application Provider: NGN operator role that offers NGN applications to the Customers making use of the services 
capabilities provided by the NGN Service Provider. It can perform user authentication at the application level 

black list: list of identity information whom parties are identified as with malicious information. This list is managed by 
the user or the service provider 

NGN operator role: activity or set of activities performed by a telecom operator played in the context of a NGN 
deployment scenario. Each activity may denote different types of roles, e.g., business role or technical role, depending 
on the nature of the services or tasks performed in each scenario. Independently of the numbers and types of roles 
identified for the players in these deployment scenarios, the following rules apply: 

• a telecom operator player is composed by one or more roles; 

• each of these roles must be considered as either a business role, a technical role or both; 

• at least one role must be considered as a business role within an administrative domain. 
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NGN Core Network Provider (NCNP): NGN operator role that relies in infrastructure supported by different types of 
high-speed technology, e. g. ATM, SDH, others, and aggregates traffic between edge nodes located in different access 
networks, or between an edge node located in an access network and an external network, e.g. PSTN, or other IP network 
types. The NCNP is also responsible for core resource management, gating, QoS control and traffic control, between the 
core network border entities, e.g. C-BGF and I-BGF, according to the transport control service requested by the NGN 
Connectivity Provider. The NCNP is also responsible for policy enforcement and NAT related handling 

NGN Connectivity Provider (NCP): NGN operator role that provides connectivity between the user and one or multiple 
Core Transport Networks. The NCP provides a connectivity service to users and therefore owns the commercial 
relationship with them and the subscriber access profile data (e.g. user authentication credentials, set of allowed QoS- 
enabled applications). The NCP is also responsible for performing admission control decisions as well as guaranteeing 
and monitoring the agreed QoS and security characteristics of traffic to and from a particular user 

NGN Access Network Provider (NANP): NGN operator role that aggregates traffic between multiple last mile access 
networks and one or multiple NGN Connectivity Providers. The NANP is also responsible for resource management, 
gating and traffic control between the User Equipment and the IP edge as appropriate, according to the transport control 
service requested by the NGN Connectivity Provider. The NANP holds the subscriber access profile (e.g. ADSL line QoS 
profile, NCP associated with a physical ADSL line, etc.) as well as policy and configuration data associated with the 
NGN connectivity provider. The NANP does not own subscriber access profile information 

NGN Service Provider (NSP): NGN operator role that offers NGN based services which share a consistent set of 
policies and common technologies. The NSP provides common functionalities e.g. user service authentication and 
identification, service control, charging, etc. Several Application Providers can use the same NSP to deliver applications 
to the Customers 

unknown party: party who is unknown by the other party (e.g. not in his Address Book), different from "anonymous") 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACR Anonymous Communications Rejection service requirements 

AMR Adaptive Multi-Rate 

AN Access Network 

CDR Charging Data Record 

CLIP Calling Line Identification Presentation 

CN Core Network 

Coix Connectivity-oriented Interconnection 

COMIF Customized Originating Multimedia Information Filtering 

COMIP Customized Originating Multimedia Information Presentation 

CPE Customer Premsise Equipment 

CS Circuit Switched 

CTMIF Customized Terminating Multimedia Information Filtering 

CTMIP Customized Terminating Multimedia Information Presentation 

DSL Digital Subscriber Line 

ECN Electronic Communication Network 

HW Hardware 

IM IP Multimedia 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

IPCAN IP-Connectivity Access Network 

IPv4 Internet Protocol version 4 

IPv6 Internet Protocol version 6 

ISDN Integrated Services Digital Network 

ISIM IMS Subscriber Identity Module 

ISP Internet Service Provider 

LI Lawful Interception 

MCID Malicious Communication Identity service requirements 

NAI Network Access Identifier 

NASS Network Attachment Subsystem 
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NAT 

NB 

NGN 

PBX 

PES 

PLMN 

PSTN 

QoS 

RACS 

SLA 

Soix 

SP 

SUB 

TDM 

UE 

URI 

UUI 

uus 

VPN 
WB 



Network Address Translation 

NarrowBand 

Next Generation Network 

Private Branch eXchange 

PSTN/ISDN Emulation Subsystem 

Public Land Mobile Network 

Public Switched Telephone Network 

Quality of Service 

Resource and Admission Control Subsystem 

Service Level Agreements 

Service-oriented Interconnection 

Service Provider 

Subaddressing 

Time Division Multiplexing 

User Equipment 

Uniform Resource Identifier 

User-to-User Information 

User-to-User Signalling 

Virtual Private Network 

WideBand 



4 Capabilities for the support of IP IVIultimedia Services 

This clause covers the requirements of the IP Multimedia services supported by the NGN IMS. 

4.1 Business models 

As specified in clause E.4.L 

4.2 Service requirements 

4.2.1 General services requirements 

As specified in clause E.4.3.1. 

4.2.2 Handling of sessions 

As specified in clauses E.4.3.2 and F.4.3.2.L4. 

4.2.3 PSTN/ISDN simulation service 

As specified in clause E.4.3.3. 

4.2.4 IMS messaging 

The capabilities to support immediate messaging and session based messaging shall be as described in TS 122 340 [1]. 

4.2.5 Presence service 

The capabilities to support Presence Service shall be as described in TS 122 141 [2]. 

4.2.6 Location service 

As specified in clause F.4.3.6. 
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4.2.7 Video telephony service 

As specified in clause E.4.3.7. 

4.2.8 Communication diversion service 

As specified in clause E.4.3.8. 

4.2.9 Subaddressing (SUB) 

As specified in clause F.4.3.9. 

4.2.1 User-to-User Signalling (UUS) 

As specified in clause F.4.3.10. 

4.2.1 1 Customized multimedia information services 

As specified in clause F.4.3.11. 

4.3 Mobility 

4.3.1 Mobility in TISPAN NGN 

As specified in clause E.4.4. 1. 

4.3.2 Voice call continuity 

The requirements for voice call continuity in TS 122 101 [14] clause 21 applies for TISPAN NGN networks. 

4.4 Numbering, naming and addressing 

As specified in clause E.4.5. 



4.5 Terminal requirements 

The present document does not specify terminal requirements. However, NGN terminals (not precluding network 
adaptors) that comply with the NGN IMS UNI interface offered by the network shall be supported by the NGN. 

The NGN IMS UNI interface is not required to support 3GPP mobile terminals in Release 1 . 

It is a service provider option to support a 3GPP IPCAN for a user to access the NGN IMS. The NGN IMS shall 
support 3GPP mobile terminals connected via the 3GPP IPCAN. 

Terminal developers guidelines are provided in annex B. 

4.6 Regulatory service requirements 

As specified in clause E.4.7. 

4.7 Access network requirements 

Any access to the NGN core shall provide IP connectivity, i.e. allow transport of IP packets between end user 
equipment and the NGN core. 
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Solutions for access to the NGN core shall support the assignment of IP addresses to the end user equipment by the 
access network. These addresses may not be routable in the public Internet. 

Solutions for access to the NGN core shall not require changes to existing access technology infrastructure. All 
solutions for access to the NGN core shall support the presence of NAT and firewalls in the access network 
environment. Impacts on access networks shall be minimized. 

An NGN deployment shall not inhibit user access to the Internet and other IP networks through existing mechanisms, 
e.g. ISP offering of internet access to DSL users. 

4.8 Customer networks 

4.8.1 General 

Access from a customer network to the NGN core shall provide IP connectivity, i.e. allow for transport of IP packets 
from the end user equipment. 

Solutions for access from a customer network to the NGN shall be able to cope with the assignment of IP addresses to 
the end user equipment by the customer network. These addresses may not be routable in the public Internet. 

Solutions for access from a customer network to the NGN shall not require technological changes to existing customer 
network technologies. 

Solutions for access from a customer network to the NGN shall have minimal impact on existing customer network 
deployments. 

The diagnostic operations on the Customer Network by an operator shall be performed in accordance with rules 
protecting the user's privacy. 

4.8.2 Home and small office networks 

Solutions for access from a Home and Small Office network to the NGN shall be able to cope with NAT and firewalls 
in the home/small office environment. 

Solutions for access from a Home and Small Office network to the NGN shall support the following configurations: 

• Direct connectivity and interaction between the individual terminals and the NGN. 

• Indirect connectivity and interaction between the individual terminals and the NGN (e.g. via IP PBXs). 



4.8.3 Corporate networks 



Solutions for access from a corporate network to the NGN shall be able to cope with NAT and firewalls in the corporate 
environment. 

Solutions for access from a Corporate network to the NGN shall support the following configurations: 

• Direct connectivity and interaction between the individual terminals and the NGN (e.g. to support Ipcentrex 
configurations). 

• Indirect connectivity and interaction between the individual terminals and the NGN (e.g. via IP PBXs). 

A mechanism shall be available in the network to provide information, if the PSTN/ISDN resources are not available. 

4.9 Interworking 

As specified in clause E.4.10. 
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4. 1 Quality of Service (QoS) 

The NGN shall support the following: 

A wide range of QoS -enabled services. 

Dynamic negotiation of QoS parameters between service and access providers based on an SLA. 

Terminals that are not capable to indicate QoS requirements as part of the service request. Terminals that are 
capable shall also be supported. 

QoS provisioning within the access segment. QoS in the core transport network is considered to be achieved 
by other means that are out of the scope of NGN Release 1 (e.g. Overprovision). 

The provisioning of QoS for application traffic where upstream and downstream flows have specific QoS 
requirements. 

An architecture that supports bandwidth reservation. 

QoS mechanisms to allow efficient use of access resource. 

In addition other specific QoS requirements are contained in [15]. 



4. 



1 Security requirements 



4.11.1 General 

As specified in clause E.4.12.1 except as follows: 

• The Access Network shall provide access connectivity to a user entitled to use the resources of the Access 
Network. 

• The NGN shall support independent verification by IMS and Access Network of the previous two 
requirements. 

4.11.2 NGN security 

As specified in clause E.4.12.2. 

4.11.3 Network domain security 

As specified in clause E.4.12.3. 

4.12 Charging and accounting 

As specified in clauses E.4.13 and F.4.13. 

4.13 Roles within an NGN 

To provide services to the users, different roles could be identified within an NGN both at the service layer and at the 
transport layer. Figure 1 represents all the roles identified. 
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Figure 1 

At the service layer 2 different roles may be identified: the NGN Service Provider and the Application Provider. The 
NGN service Provider provides services directly to the Customers, the Application Provider can provide more complex 
value added applications to the Customers, using capabilities of the NGN Service Provider. 

At the transport layer 3 different roles may be identified: NGN Access Network Provider, NGN Connectivity Provider 
and NGN Core Network Provider. Each role owns both Functional Control elements (e.g. parts of RACS or NASS) and 
transfer functions (e.g. AN, IP edge, xBGF, etc.). It is not within the scope of the present document specify the 
architectural elements belonging to the different roles. 

In addition to have a complete picture, a Customer environment shall be identified. 

These roles are technical roles: different roles can be played at the same time by a single Telecom Operator defining in a 
such way a variety of business roles. 



5.1 



PSTN/ISDN emulation service 



Business models 



The business model envisaged for PSTN/ISDN Emulation Service is the replacement (in whole or part) of an existing 
PSTN/ISDN network based on TDM with an Emulation based on IP technology. An alternative business model is the 
provision of PSTN/ISDN service over connections derived from broadband service, which compete with the existing or 
Emulated PSTN. Both business models may co-exist in the same market place. 

A NGN service provider shall be capable of connecting to other service provider via: 

• an interconnect model where bi-lateral Service Level Agreements (SLA) are established between two service 
providers; 

• an interconnect model where intermediate network(s) can provide interconnect on behalf of multiple service 
providers (and may be based on a single Service Level Agreement between the SP and their intermediate 
service provider). 

A single NGN service provider shall be able to choose to support either of the interconnect models, or both of the 
interconnect models simultaneously. 
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5.2 Service requirements 



The NGN shall support PSTN /ISDN emulation that provides the user with an identical experience to that of the 
existing PSTN/ISDN. 

The NGN shall support the ability for a service operator to emulate one or more of their PSTN/ISDN services. 

The NGN shall support service capability definitions inherited from existing PSTN/ISDN specification. The service 
descriptions of the existing services for any particular network are outside the scope of the present document. 

It is an objective that the user shall be unaware of a change from legacy PSTN/ISDN to PSTN/ISDN emulation for 
those services that are emulated. For each emulated service, the service capability definitions are inherited from existing 
PSTN/ISDN specifications. Specific service requirements related to PSTN/ISDN Emulation are described in the 
following clauses. 

An automatic re-routing (cranckback) mechanism for handling of the communications blocked due to unavailability of 
PSTN/ISDN resources shall be provided by the network. 



5.3 IVIobility 



There is no requirement to support mobility or a nomadic capability for PSTN/ISDN Emulation. There are no 
additional mobility requirements. 

This does not prevent the existence of user nomadism where it is implicit in the chosen business model nor does it 
require that nomadism be actively prevented. 

5.4 Numbering, naming and addressing 

The users of PSTN/ISDN Emulation will be allocated numbers (or number ranges) in the appropriate E. 164 number 
space allocated by the national numbering authority. The nature of this E. 164 number will vary from operator to 
operator and from country to country. The design shall permit the use of both geographical and non-geographical E.164 
numbers. 

There is no requirement to support the use of non-E.164 names within PSTN/ISDN Emulation but the use of non-E.164 
names is not precluded. 

PSTN/ISDN emulation places no new requirements to support number portability. 

5.5 Terminal requirements 

The NGN shall support terminals that use existing PSTN/ISDN interfaces. 

Whilst the NGN has no role in standardizing terminals it is recognized that a key aspect of the PSTN/ISDN emulation 
subsystem is the ability to enable PSTN/ISDN replacement whilst maintaining all the existing services in the network. 

NOTE: More advanced terminals may use the PSTN/ISDN emulation subsystem to provide identical PSTN/ISDN 
services to the user. Such advanced terminals may or may not be able to access additional services not 
related to PSTN/ISDN emulation but the functions of such terminals are not subject to standardization 
within the Release 1 of NGN. 

5.6 Regulatory service requirements 
5.6.1 Lawful Intercept service requirements 

All implementations of PSTN/ISDN Emulation shall provide the ability to provide Lawful Interception in accordance 
with national requirements. Where possible the packet interception handover interfaces should be made available to 
authorities to avoid the ability of targets to maintain covert channels not monitored by TDM handover interfaces. Packet 
handover is most important for derived service where the packet stream is not under direct control of the provider of the 
Electronic Communication Network. 
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The capabilities to support Lawful Intercept for Emulation shall be as described in TS 187 005 [17]. 

5.6.2 Emergency service requirements 

The capabilities to support the Emergency Service shall be as described in TS 102 424 [3]. 

5.6.3 Malicious Communication Identity service requirements (MCID) 

MCID is a service which is expected to be provided in the context of the European Telecoms Privacy Directive or 
equivalent regulations in other jurisdictions. The service is required for all speech calls irrespective of which network 
originated the call. It is normally provided following a request from the customer concerned and may be subject to 
authorization. 

The served user may be provided with the capability of explicitly declare a call as malicious. 

5.6.4 Anonymous Communications Rejection service requirements (ACR) 

The service capability definition for this service is inherited from existing PSTN/ISDN specifications and no new 
requirements are identified. 

5.7 Access networks 
5.7.1 Wireline access 

The deployment of an NGN supporting PSTN/ISDN emulation may support existing access methods and access 
network technologies. The PSTN/ISDN User-Network Interface shall not be affected. 

5.8 Customer networks 

5.8.1 Home and small office networks 

In the case of PSTN/ISDN Emulation used to replace an existing analogue or TDM network these are handled in the 
same way as the network which is being replaced or substituted. 

Where the business model involves derived voice the customer will present lines to either an Access Gateway or a 
Residential Gateway as appropriate. In some cases there will be a terminal that offers service in an alternative manner 
but that is not within the scope of the present document. 

A Residential Gateway may be situated within a Customer Access Gateway or on the customer network side of it. The 
Customer Access Gateway may use any suitable access technology. 

In addition where existing Primary Rate ISDN or equivalent services are provided the PSTN/ISDN Emulation may 
support them. The actual signalling systems and methods of presentation supported are a national matter, supported by 
the list of designated standards published by the European Commission. 

5.8.2 Corporate networks 

Within the context of the PSTN/ISDN Emulation Corporate Networks may continue to be supported. The actual 
signalling systems and methods of presentation supported are a national matter supported by the list of designated 
standards published by the European Commission. This support may extend to the provision of VPN services using 
signalling systems and methods of presentation which are provided on a national basis and those that rely on European 
Standards. 
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5.9 Interworking 

5.9.1 Interworking with legacy PSTN/ISDN 

PSTN/ISDN emulation shall provide interfaces to PSTN/ISDN networks. 

The NGN shall support the ability for the interconnection between two PSTN/ISDN and/or emulation networks to 
remain unchanged from the legacy case. 

PSTN/ISDN Emulation shall provide a high level of interoperability with the services in the PSTN/ISDN being 
emulated. The degree to which service interoperability is provided is a matter for operators of Public Electronic 
Communications Networks and, in some cases, national regulators. 

A mechanism shall be available in the network to provide information, if the PSTN/ISDN resources are not available. 

5.9.2 Interworking with PSTN/ISDN emulation 

PSTN/ISDN Emulation shall provide a high level of interoperability with the services in other Emulated PSTN/ISDN 
networks. The degree to which service interoperability is provided is a matter for operators of Public Electronic 
Communications Networks and, in some cases, national regulators. 

5.9.3 Interworking with PLMN 

5.9.3.1 Interworking with IMS based PLMN 

Inter-working with the part of a PLMN that is based on an IMS shall be as described for inter-working with a NGN IMS 
network. 

5.9.3.2 Interworking with PLMN - CS Domain 

Inter- working with the circuit switched part of a PLMN shall be as described above for Inter-working with a 
PSTN/ISDN network. 

5.9.4 Interworking with packet cable network 

Inter-working with the Packet Cable network shall be as described for Inter-working with a legacy PSTN/ISDN 
network or as described for Inter-working with an emulated PSTN/ISDN network. 

The choice of method is at the discretion of the operators concerned or as directed by a regulatory authority. 

5.9.5 Interworking with NGN IMS network 

Refer to clause E.4.10.2. 

5.9.6 Interworking with other networks 

Inter-working with non-IMS and non-TDM network is the same as for inter-working with: 

i) A TDM based PSTN/ISDN as described above; or 

ii) Another PSTN/ISDN Emulation as described above. 
The choice of method is at the discretion of the operators concerned or as directed by a regulatory authority. 
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5.10 Quality of Service (QoS) 



The PSTN/ISDN Emulation shall provide QoS transmission facilities to enable the same end-to-end performance 
requirements of the PSTN to be met. This includes any reservation of bit rate through the Access transport and also 
includes any transcoding facilities that may be needed. 



5.1 1 Security requirements 



A PSTN/ISDN Emulation shall meet the security requirements placed on a national PSTN/ISDN network. Where 
appropriate, requirements and mechanisms may vary to take account of the underlying NGN and IP technology. 

5.12 Charging and accounting 

The requirements and mechanisms for charging are a national matter. 

6 Codecs services 

The following requirements apply to audio and video codecs support within the network. 

6.1 General 

It is the responsibility of entities at the rim of the NGN (e.g. NGN-TE) and Network equipment originating and 
terminating the NGN IP media flows, to negotiate and select a common codec for each "end-to-end" media session. 
Therefore the NGN shall allow end-to-end negotiation of any codec between NGN entities (terminal, network 
elements). 

6.2 Audio codec 

In order to enable interworking between the NGN and other networks (including the PSTN, mobile networks and other 
NGNs) the NGN must be capable of receiving and presenting G.71 1 coded speech when interconnected with another 
network. When a packetization size is not selected by codec negotiation between terminals and/or network elements or 
agreed by bilateral arrangement, a speech packetization size of 10 ms samples should be used for G.711 coded speech; 
this is recommended as an optimum value balancing end-to-end delay with network utilization. It is recognized that 
there may be network constraints which require that a higher value is agreed by bilateral arrangement; in such cases a 
value of 20 ms is recommended. 

NOTE 1 : Where a packetization size is selected by codec negotiation between terminals and/or network elements 
the present document places no requirements on the value to be selected. 

NOTE 2: The above does not put any requirement about the codecs to be supported by terminals nor does it 
mandate that NGN networks shall support audio transcoding between any arbitrary codec to ITU-T 
Recommendation G.711 [27]. 

In addition, support for the following audio codecs is recommended: 

AMR: in order to support 3GPP terminals and to facilitate the interwork with 3GPP network. 

G.729A: in order to facilitate the interwork with existing VoIP networks and support existing VoIP terminals. 

EVRC/EVRC-B: in order to support 3GPP2 terminals and to facilitate interworking with 3GPP2 networks. 
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6.3 Wideband codecs 

6.3.1 General 

Clause 6.1 shall take precedence over this clause, to reduce transcoding and improve both wideband interoperability and 
end to end quality. 

Wideband audio is an optional capability that may be supported by: 

• entities at the rim of the NGN (e.g. NGN-TE) which have a wideband audio ability; 

• Network equipment originating and terminating the NGN IP media flows with wideband audio content. 

Terminals providing wideband audio capabilities shall also have NB capability and comply with clause 6.2. 

Network equipment providing wideband audio capabilities shall also have NB capability and comply with clause 6.2. 

Audio transcoding may be performed to provide end-to-end service interoperability, but should be avoided wherever 
possible. 

6.3.2 WB codecs in terminals 

Terminals originating and terminating end to end IP media flows in NGN, supporting wideband audio should provide 
one or more of the following wideband codecs: 

• ITU-T Recommendation G.722 [ 1 0] . 

NOTE 1 : Required for DECT NG user equipment, used in some VoIP and/or legacy user equipment. 

• AMR-WB/G.722.2 [11]. 

NOTE 2: Required for 3GPP user equipment and/or user equipment with mobility according to 3GPP access. 

• ITU-T Recommendation G.729. 1 [12]. 

NOTE 3: Used in some DECT NG user equipment, some VoIP and/or legacy user equipment. 

• EVRC-WB [13]. 

NOTE 4: Required for 3GPP2 user equipment and/or user equipment with mobility according to 3GPP2 access 

NOTE 5: Terminals may provide any other codecs in addition to the above list. 

NOTE 6: Exceptionally, terminals providing one or more wideband codecs none of which are in the above list (e.g. 
existing/legacy terminals) should be permitted in NGN. Such terminals may experience limited wideband 
audio interoperability. 

6.3.3 WB codecs in networks 

Network equipment originating and terminating end to end NGN IP media flows, supporting wideband audio should 
provide the following wideband codecs: 

• ITU-T Recommendation G.722 [10]. 

NOTE 1 : To support DECT NG user equipment, some VoIP and/ or legacy user equipment and/or interworking to 
other networks. 

• AMR-WB/G.722.2 [11] 

NOTE 2: To support 3GPP user equipment, user equipment with mobility according to 3GPP access and/or 
interworking to 3 GPP networks. 

• ITU-T Recommendation G.729. 1 [12]. 
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NOTE 3: Where required to support DECT NG user equipment, VoIP and/or legacy user equipment and/or 
interworking to some VoIP and legacy networks. 

• EVRC-WB [13]. 

NOTE 4: Where required to support 3GPP2 user equipment, user equipment with mobility according to 3GPP2 
access and/or interworking to 3GPP2 networks. 

6.3 Video codec 

In order to enable the interworking for video communication services between an NGN Network and other Networks 
the support of the H.263 profile and H.264 baseline profile codecs is recommended. 

NOTE: The above does not put any requirement about the codecs to be supported by terminals nor does it 

mandate that NGN networks shall support video transcoding between any arbitrary codec and ITU-T 
Recommendations H.263 [28] or H.264 [29]. 



7 Network attachment requirements 

The user network profile contains user access authentication data and information related to the required network access 
configuration. 

The NGN shall support the re-configuration of services available to the user when the user is nomadic and accesses 
their services from a location other than the subscribed-to location. Services may be dependent on any or all of: the user 
device, the access network and arrangements (e.g. roaming agreements) between the Application provider and the 
access network provider. The access network shall allocate resources in accordance to the services to be provided. 

In access roaming scenarios, those access networks that provide access to NGN services shall be able to 
authenticate/authorize access to the network based on information retrieved from the access networks where the user is 
subscribed to. 

To guarantee the interoperability of roaming services, the NGN access network attachment procedures shall support 
access network authentication based on a standardized method for identifying users at access network level (e.g. the 
NAI mechanism specified in RFC 2486 [18]). 

NAI based user authentication shall be supported. 

NASS shall support the capability to receive indications from control, transport or application subsystems that are 
interested to register to certain NASS events. 

The notification related to such an event will then be conditionally propagated to the subsystems that have registered. 

NOTE: Backwards compatibility must be kept, meaning that this capability is not applicable to IMS and PES. 



8 CPE configuration 



The NGN shall be able to provide configuration parameters and obtain operational status of the CPE. This includes the 
ability to provide SW upgrade, service configuration, collect operational status. 



9 Network management 

Network Management requirements shall be as described in TS 188 003 [4]. 
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1 Control of processing overload 

The NGN shall have mechanisms available to control overload that: 

1) automatically maximize effective throughput (i.e. admitted service requests/sec) at an overloaded resource; 

2) achieve this throughout the duration of an overload event, and irrespective of the overloaded resource's 
capacity or of the number of sources of overload; 

3) are configurable by the service provider so that, under processing overload, a high proportion of response 
times at overloaded resources are low enough so as not to cause customers to prematurely abandon service 
requests; 

4) should be possible to be applied within a service provider's NGN, and between different service providers' 

NGNs; 

5) should be possible to be applied within an NGN subsystem (e.g. IMS, PSTN/ISDN emulation) and between 
different NGN subsystems. 

NOTE: As a general rule, an NGN's call, session and command processing resources can experience prolonged 
processing overload under the appropriate circumstances (e.g. partial, or full, server failure, high rates of 
incoming service requests). Consequently, it needs to be equipped with some form of overload detection 
and control (including expansive controls such as load balancing and resource replication), in order to 
keep response times just low enough under such processing overload to preclude customers abandoning 
their service requests prematurely. 



11 IP addressing 



The Operator of an NGN infrastructure may base the implementation on IPv4 only, IPv6 only or both. The choice is an 
operator option. 

NOTE 1 : It should be recognized that a mixture of IPv4 and IPv6 within a single operator domain can cause 
problems for service delivery. 

NGN operators may support customer equipment using IPv4 only, IPv6 only or both at an IP-based User-Network 
Interface. The choice is an operator option. 

NOTE 2: It is assumed that IPv6 based customer equipment can also support IPv4 at the User-Network Interface. 



12 NGN interconnection 
12.1 General 

The interconnection of Next Generation Networks may be grouped in: 

• Service-oriented Interconnection (Soix). 

The physical and logical linking of NGN domains that allows carriers and service providers to offer services over NGN 
(i.e. IMS and PES) platforms with control, signalling (i.e. session-based), which provides defined levels of 
interoperability. This does apply for carrier-grade voice and/or multimedia services over IP interconnection. The level 
of interoperability depends e.g. on services. Quality of Service, security. 

• Connectivity-oriented Interconnection (Coix). 

The physical and logical linking of carriers and service providers based on simple IP connectivity irrespective of the 
levels of interoperability. For example, an IP interconnection of this type is not aware of the specific end-to-end service 
and, as a consequence, service-specific network performance, QoS and security requirements are not necessarily 
assured. This definition does not exclude that some services may provide a defined level of interoperability. However, 
only SoIx fully satisfies NGN interoperability requirements. 
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NGN shall support Coix interconnections. 
NGN shall support Soix interconnections. 

NOTE: IPTV interconnections are not covered by Solx and Colx. 
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Figure 2 

Figure 2 describes the Solx and Colx interconnection and NGN strata involved. 

The Colx interconnection includes only the transport stratum and is independent of any service stratum functionalities. 

The Solx interconnection includes both service and transport strata, deployment scenarios include both direct and 
indirect interconnection for the media path between the two NGNs. 

1 2.2 Requirements for Solx interconnection 

The following requirements for Solx interconnections shall be addressed: 
Signalling: 

• Support of service identification. 

• Support of service interoperability. 
Codec: 

• Codec support and codec usage as specified in clause 6 of the present document. 
Routing: 

• Support of routing based on service. 
Security 

Support of: 

• Lawful interception. 

• Support of appropriate privacy. 

• Support of authorization. 
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• Support of authentication and access control. 

• Support of communications and data security (including integrity and confidentiality). 

• Support of DoS protection. 
Charging and accounting: 

• Support of CDR generation. 

• Support of detailed service accounting reporting. 
Resource, QoS and SLA: 

• Support of required resource allocation. 

• Support of admission control. 

• Support of address and port translation functionalities. 

• Support of policy control. 

• Support of load balancing. 

• Support of availability and reliability. 

• support of QoS reporting. 

12.3 Soix interconnection between IIVIS platforms 

The interconnection link between two Carriers/Service Providers shall be "aware" of specific NGN services. It may be a 
physical or a logical link which carries both data and signalling bearers. The Point of Interconnection shall be a 
standardized interface. 

The Resource Control shall control the resources on the interconnection link in order to deal with different services data 
and signalling bearer characteristics. 

Over-provisioned resources on the interconnection link may be inefficient in terms of total interconnection link 
bandwidth usage. 

Security and accounting features shall be taken in account. 

In case of Transit scenario, the operators and/or service providers shall guarantee the end-to-end interoperability of 
services over the SoIx Interconnection in a standardized way. 

12.4 SoIx interconnection between IIVIS and other IP platforms 

The interconnection link shall be "aware" of specific NGN service carriers (dimensioned to carry both data and 
signalling bearer). 

The interconnection link between the two Carriers/SPs shall be defined similar to the previous scenario. 

The service interoperability and the service interworking shall be ensured in a standardized way. 

Over-provisioned resources between the two Carrier/SP domains may satisfy some QoS and Service Level 
Agreements (SLA) requirements. 

NOTE: Over-provisioning will not guarantee any improvements on the base of traffic growth, even if the resource 
allocation control will be implemented on both platforms. 

In the case of Transit scenario the Carriers/SPs can guarantee the service end-to-end interoperability. 

Interworking shall take in account both signalling, security and/or accounting features. 
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13 IPTV 

13.1 General 

To be provided. 

13.2 Service-related requirements 

To be provided. 

13.3. Network capabilities 

To be provided. 



14 Transport stratum 

Void. 
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Annex A (informative): 

Basic communication cases for IIVIS networks 

This informative annex is part of Common IMS and needs to be transferred to 3GPP. 

A basic communication case can be described on a per IMS domain basis by stating the IMS domain entry point and an 
exit point for the communication as shown in figure A. 1 . 

The following general types of entry /exit point can be identified for NGN Release 1 : 

• Access (for communication to from NGN terminals). 

• Interconnect to non-IMS network. 

• Interconnect to other IMS domain. 

• Internal network resource (e.g. a conference bridge for conferencing services). 

As a general rule a NGN shall support the following basic communication cases on a per NGN network basis. 

Table A.I 



From 
(entry point) 


To (exit point) 


Access Network 


Interconnect to other 
IMS domain 1 


Interconnect to 
non-IMS network 


Internal Network 
Resource 


Access Network 


Required 


Required 


Required 


Required 


Interconnect to other 
IMS domain 1 


Required 






Required 


Interconnect to 
non-IMS network 


Required 




Required 


Required 


Internal Network 
Resource 


Required 









It is not precluded that other, more complex communication cases may be provided by service level concatenation of 
basic communication cases, e.g. by means of call diversion services. 




Figure A.I : Graphical representation of supported basic communication cases 
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Annex B (informative): 

Guidance for terminal implementation 

The first two paragraphs are part of Common IMS and need to be transferred to 3GPP. 

For a terminal to attach to the TISPAN NGN IMS Subsystem it should be capable of using an ISIM to authenticate to 
the NGN IMS. 

However, this does not preclude the use of non-ISIM capable terminals, if access using an ISIM application in another 
device is supported. Authentication based on line authentication (as in clause 4. 11) if applicable to the access is also 
supported. 

Software upgrades may be required e.g. for security purposes, as well as minor HW upgrades, e.g. chip card reader. 

Solutions for access to the NGN core shall support existing terminals (e.g. personal computers). The client software 
should be deployable making use of download techniques but should not impact the current operating system. 
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Annex C (informative): 
Void 
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Annex D (informative): 
Void 
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Annex E (normative): 

Release 7 parts of Common IMS 



This annex contains candidate text to be replaced with the suggested references to 3GPP specifications. There may be 
also suggestions what needs to be changed if not all text of a clause cannot be replaced by one or more references. 
When agreed this text replaces the corresponding clauses in the main body. 



E.1 Void 

E.2 Void 

E.3 Void 

E.4 Capabilities for the support of IP Multimedia Services 

This clause covers the requirements of the IP Multimedia services supported by the 3GPP IMS (TS 122 228 Release 7). 

E.4.1 Business models 

The IMS supports business agreements between the access network operator and the network operator providing IMS 
services (IMS operator). 

The IMS shall be able to offer services to users that are attached to access networks owned by another operator. 

The service offering may be restricted by the capabilities of the access network and the business agreement between the 
access network operator and the IMS operator. 

The IMS shall support at least the following operator's business domain relationships: 

a) Access network to IMS relationships 

a. 1) Access network and the IMS network it connects to, belong to the same operator as shown in figure E. 1 . 




Access network 
Operator A 





Intr a-operat or 
elationshipT~^>^ r"'^^ ^ NGN 




Figure E.1 

a.2) Access network and the IMS network it connects to, belong to different operators having an 
interconnection agreement as shown in figure E.2. 
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Relationship b 




Access network 
Operator B 




Figure E.2 



b) IMS level relationships 



NGN 




b.l) The IMS network (e.g. 3GPP or NGN) to which the access network connects and the Home IMS 

network (e.g. NGN or 3GPP) which provides the IMS services belong to different operators as shown in 
figure E. 3. 




Figure E.3 

b.2) The IMS network (e.g. 3GPP or NGN) to which the access network connects and the Home IMS 
network (e.g. NGN or 3GPP) which provides the IMS services are the same as shown in figure E.4. 



Relationship d 




NGN 




Figure E.4 

b.3) The IMS network (e.g. 3GPP or NGN) to which the access network connects and the Home IMS 

network (e.g. NGN or 3GPP) which provides the IMS services belong to the same operator as shown in 
figure E.5. 




Figure E.5 
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A IMS operator shall be capable of connecting to other network operators via: 

• an interconnect model where bi-lateral Service Level Agreements are established between two operators; 

• an interconnect model where intermediate network(s) can provide interconnect on behalf of multiple operators 
(and may be based on a single Service Level Agreement between the operators and their intermediate network 
provider). 

A single IMS operator shall be able to choose to support either of the interconnect models, or both of the interconnect 
models simultaneously. 

E.4.2 Void 

E.4.3 Service requirements 
E.4.3.1 General services requirements 

SeeTS 122 228 [9]. 

The principle of access independence, as defined by the business models described above, shall be supported. 

It is desirable that an operator should be able to offer services to their subscribers regardless of how they obtain an IP 
connection through an access network as long as there is a business (roaming) agreement between access operator and 
IMS operator. 

IP multimedia sessions shall be able to support a variety of different media types. 

Within each IP multimedia session, one or more IP multimedia applications shall be supported. 

The network shall provide the capability for the user to invoke one or more IP multimedia sessions. Where more than 
one application is supported within a multimedia session by the network, the user may activate concurrent IP 
multimedia applications within each IP multimedia session. 

The network shall store information about the state (e.g. attached/non-attached) of a user's access connection, whether 
the user is roaming or not. According to policies this information may be provided to applications. 

The network shall have the capability to hold user location information, whether the user is roaming or not. According 
to policies this information may be provided to applications. 

The network shall deliver additional information (e.g. Picture, Video, text), provided by the user, to the parties 
involved, during any phase of the communication. The additional information may not be related to any media flow. 

E.4.3. 2 Handling of sessions 

SeeTS 122 228 [9]. 

E.4.3. 2.1 Handling of session establishment 

An automatic re-routing (cranckback) mechanism for handling of the communications blocked due to unavailability of 
PSTN/ISDN resources shall be provided by the network. 

E.4.3. 2.1 .1 Presentation of session originator identity 

The network shall present the identity of the session originator (as in clause 4.5). The network shall suppress the 
presentation of the identity when requested by the session originator. 

NOTE: The requirements for support of emergency communications may over-ride the user request for 
suppression. 

Multiple identities should be supported within the same subscription. Personal service profiles per each identity within 
the same subscription should be supported. 
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E. 4. 3. 2.1 .2 Negotiation of an incoming session 

Interaction with the user profile shall be supported, and additionally direct interaction with the user may be required. 
Refer to clause E.4.3.2.4 for further details on capability negotiation on an incoming IP multimedia session. 

E.4.3.2.1 .3 Accepting or rejecting an incoming session 

The network shall support the capability for the user to accept, reject, ignore or re-direct an incoming IP multimedia 

session. 

E.4.3.2.1. 4 Void 

E.4.3.2.2 Handling of an ongoing session 

E. 4. 3. 2. 2.1 User modification of media in an ongoing session 

The user shall be able to negotiate the addition or deletion of media components of IP multimedia applications during 
an IP multimedia session. Refer to clause E.4.3.2.4 for further details on capability negotiation during an IP multimedia 
session. 

E. 4. 3. 2. 2. 2 Presentation of identity of session terminator 

The network shall support the capability to present to the session originator the identity (as in clause 4.5) of the session 
terminator. The network shall suppress the presentation of the identity when requested by the session terminator. 

NOTE: The requirements for support of emergency communications may over-ride the user request for 
suppression. 

E.4.3.2.3 Handling end of session 

If there are one or two participants in the IP multimedia session, the network shall end an IP multimedia session at any 
time during the session, when requested by any of the IP multimedia session users. The network may end an IP 
multimedia session at any time during the session (e.g. in failure conditions). 

If there are more than two participants in the IP multimedia session the network may end an IP multimedia session at 
any time during the session, when requested by any of the IP multimedia session users. The network may end an IP 
multimedia session at any time during the session (e.g. in failure conditions). 

E.4.3.2.4 Capability negotiation 

The network shall provide the capability for IP multimedia applications (whether it is an application of a user or the 
network) to negotiate their capabilities by identifying and selecting the available media components, QoS, etc. of IP 
multimedia sessions. The network shall support the capability for negotiation to take place on invocation, acceptance 
and during an ongoing IP multimedia session (e.g. following a change in UE capabilities, change in media types, etc.). 
The user, network, or an application on behalf of the user or network may initiate capability negotiation. 

In order to support user preferences for IP multimedia applications, the capability negotiation shall take into account the 
information in the user profile whenever applicable. This includes the capability to route the IP multimedia session to a 
specific UE, when multiple UEs share the same IMS service subscription. 

E.4.3.2.5 Redirecting of IP IVIultimedia sessions 

The network shall support the capability for the user, or the network on behalf of the user, to identify an alternative 
destination for an IP multimedia session or individual media of an IP multimedia session. The originating entity, 
terminating entity or the network on their behalf, may initiate redirection to alternative destinations. It shall be possible 
for redirection to be initiated at various stages of an IP Multimedia session. For example: 

• Prior to the initial request of an IP Multimedia session. 

• During the initial request for an IP Multimedia session. 
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• During the establishment of an IP Multimedia session. 

• While the IP Multimedia session is ongoing. 

Redirection can be applied for all Multimedia sessions unconditionally or it can be caused by any of a set list of events 
or conditions. Typical causes could be: 

• Identity of the originator. 

• Location or presence of the originator or terminator. 

• If the terminator is already in a session. 

• If the terminator is unreachable or unavailable in some other way. 

• If the terminator does not respond. 

• After a specified alerting interval. 

• User's preference on routing for specific IP Multimedia session based on the capabilities of multiple UEs 
sharing the same IMS service subscription. 

• Time of day. 

E.4.3.2.6 User busy 

E. 4. 3. 2. 6.1 User determined user busy 

The network shall support the capability of a user to reject an incoming IP multimedia session with an indication of 
"user busy". This indication may be used by the network as a trigger for certain services e.g. Call Forwarding on Busy. 
If the session rejection is propagated back to the originator, the "user busy" indication must be provided as the cause of 
the rejection. 

The conditions for user determined "user busy" include: 

• the session is offered to a single contact that rejects with a "user busy" indication; or 

• the session is offered to multiple contacts with a single public identity, and one contact rejects with a "user 
busy" indication on behalf of the set of contacts; or 

• the session is offered to multiple contacts; and 

none of the contacts progress the session; and 
one or more of the contacts rejects with a "user busy" indication. 
NOTE: A contact is e.g. a terminal, a UE, or some other kind of equipment in the user premises. 

E. 4. 3. 2. 6. 2 Network determined user busy 

The capability of network determined user busy is a network option. 

The network may determine busy conditions at the time an incoming IP multimedia session is about to be offered. 

The conditions for network determined user busy are identified, on a per subscription basis, based on the availability of 
limited resources assigned to the terminating user, or due to other information such as presence. 

The conditions for network determined "user busy" include: 

• the maximum number of total communications permitted has been reached; 

• the maximum number of simultaneous media streams supported at the given subscriber's interface(s) has been 
reached; 

• the maximum bandwidth supported at the given subscriber's interface(s) has been reached. 
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• subscriber making himself "busy" in a subscriber profile, involved in the incoming multimedia session. 

The network determined user busy condition may be used to trigger certain services (e.g. Call Forwarding on Busy), or 
reject the session, or both. If the session rejection is propagated back to the originator, a "user busy" indication must be 
provided as the cause of the rejection. 

In addition, a further condition, "approaching network determined user busy" that is related to the Network determined 
user busy condition, may be provided. This condition may be used to trigger certain services. However, this condition is 
not a busy condition and shall not cause a "user busy" indication being sent towards the session originator. 

The conditions for approaching network determined user busy are identified, on a per subscription basis, based on the 
availability of limited resources assigned to the terminating user. 

The conditions for approaching network determined user busy include: 

• a pre-determined number, or less, of communications are available (i.e. the maximum number of 
communications minus the current number); or 

• a pre-determined number, or less, of simultaneous media streams available (i.e. the maximum number of 
simultaneous media streams minus the current number); or 

• a certain limit in the bandwidth used at the given subscriber's interface(s) has been reached. 

E.4.3.2.7 Service re-configuration 

To allow rich service offerings by networks without overloading the terminals and clients, user centric networking 
service capability may be offered. With the intelligence in the network, the services can be downloaded and used only 
when they are requested. 

E.4.3.2.7. 1 General requirement 

As a service provider/network option the IMS may support the re-configuration of services available to the user when 
the users access its services from a location other than the home (subscribed-to) location. 

The services may be dependent on the access network and arrangements between the Application provider and the 
access network provider including roaming cases. 

The network shall be able to determine the capability of a user device based on the capability announced by the end user 
device before offering its services/applications to the end user. 

The network shall be able to announce one or more of the network services and applications to the user device based on 
the user device capability and the requirements of one or more network services and applications supported by the 
network 

The network shall accept the customized service profile requested by the end user after successful 
authentication/authorization of the user, and update the subscription database accordingly for billing/charging purposes 
and for future record of the user preferences. 

The lifetime of a service client downloaded on a user device shall be agreed between the user and the network before the 
download. The service provider/network provider shall be able to determine the lifetime. 

Basic services shall be supported permanently on the user device (e.g. voice services). 

E. 4. 3. 2. 7. 2 Service reconfiguration when roaming 

When roaming into a new network, the service client(s) may be overwritten by new applicable version depending on the 
capability of the network and the offered service in that network. 

E. 4.3.3 PSTN/ISDN simulation service 

This clause is part of Common IMS. 
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The IMS shall provide the capability for a service operator to simulate one or more PSTN/ISDN services. PSTN/ISDN 
simulation that provides the user with an experience that may or may not differ to an existing PSTN/ISDN experience. 
The way in which PSTN/ISDN services are delivered shall not impact on the delivery of new IMS services. 

The specific requirements for the PSTN/ISDN simulation service are described in TS 181 002 [22]. 

E.4.3.4 Void 

E.4.3.5 Void 

E.4.3.6 Void 

E.4.3.7 Video telepinony service 

See TS 122 101 [14], TS 122 173 [19] and TS 122 228 [9]. 

The capabilities to support a video telephony service are described in TS 181 001 [23]. 

E.4.3.8 Communication diversion service 

SeeTS 122 173 [19]. 

The Communication Diversion Service shall be enhanced to allow user-controlled notification of communication 
diversions to the diverting user. The network shall provide the user with the subscription option to control which 
notifications the user wants to receive and to control the rate at which notifications about the communication diversions 
the users wants to receive. 

E.4.3.8. 1 Communication Diversion Notification 

The network shall provide as a subscription option the notification capabilities to the served user. The user may control 
the rate (how frequent) and the content of the communication diversion notification in a standardized format 

In order to set criteria for the notification to the user, the network shall accept parameter from the user, e.g.: 

• the identity of the caller (only if there is a match then information about this specific Communication 
Diversion will be notified to the diverting user); 

• identity of the diverting-user (only if there is a match then information about this specific Communication 
Diversion will be notified to the diverting user); 

• identity of diverted-to-party (only if there is a match then information about this specific Communication 
Diversion will be notified to the diverting user); 

• time range of diversion (this specifies a time-range, within which all Communication Diversions would be 
notified to the diverting user. If present, then any communication diversion outside of this time-range shall not 
be notified to the diverting user); 

• reason of diversion (the diverting user can select that only those communication diversions which match the 
herein specified reason be notified). 

For triggering the notification to the user, the network shall accept parameters from the user, e.g.: 

• time (this specifies a time at which notifications of communication diversion are sent to the user. It may be 
specified within an interval-format to allow regular triggering of notifications of communication diversions 
which took place in that time-interval. If absent, it indicates that notifications are sent immediately when the 
communication diversion takes place); 

• presence status (this specifies a presence state of the user, within which the user expects to receive 
notifications about communication diversions. If absent, it indicates that notifications are sent immediately 
irrespective of user's availability information). 
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The communication diversion notification from the network to the user may include, e.g.: 

• identity of the caller (this information provides information to the diverting user for identifying those 
communication diversions happening for this calling user's identity; 

• information of diverting-user (this is required when the diverting user has multiple user identities and is 
interested in knowing for which specific user identity was the communication diversion triggered); 

• information of the diverted-to -target (the user identity of the diverted-to user, to whom the communication is 
being diverted, would be informed to the diverting user); 

• time of diversion (the time of the communication diversion would be informed to the diverting user. This helps 
the diverting user to identify and verify if indeed the communication diversions are expected at those times); 

• reason for diversion (provides the diverting user information to ascertain that indeed the reason for diversion is 
as per his expectations); 

• communication diversion rule (this information identifies the communication diversion rule of Release 1 which 
was set by the user, and executed to result in the communication diversion, which is being notified to the user). 

If the user has not subscribed to the communication diversion notification capability or the network does not provide the 
subscription option to the user, the diversion notification capability of the communication diversion service of Release 1 
shall apply. 

E.4.3.9 Void 
E.4.3.10 Void 
E.4.3.11 Void 

E.4.4 Mobility 

E.4.4.1 Mobility in TISPAN NGN 

See TS 122 101 [14] and TS 122 228 [9]. 

The IMS shall support terminal portability as defined in TR 180 000 [16]. 

The IMS shall support nomadism, as defined in TR 180 000 [16], and described below. 

The IMS shall support the capability for a user to change to a different device or devices connected to one or more 
access networks to gain access to their services. 

The IMS shall support the capability of the user to change network access point whilst moving. 

NOTE 1 : Where the access network technologies are identical and owned by the same access network operator, 
session continuity or handover may be supported if the technology allows. Where session continuity or 
handover is not supported, the user's service session is completely stopped. 

NOTE 2: Where the access network technologies are not identical, session continuity or handover need not be 
supported. 

The IMS home network and visited network shall support the capability of providing services from the IMS home 
network to a user connected to the visited network. This is shown by figure E.3 under b.l) within clause E.4.1. 

Services should be able to be reconfigured so as to be suitable for the target network and target device. The service shall 
be reconfigured at the time the user first accesses the service from a new location. 

For particular services, mobility shall not interfere with the provision of all information required by the service 
(e.g. geographic location information). 
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E.4.5 Numbering, naming and addressing 

See TS 123 228 [20] clauses 4.3 and 7.5.1, and TS 123 003 [21]. 

The IMS shall provide the capability to uniquely identify each user. This Identity Information shall include at least the 
asserted public identity. This identity information is verified. 

Both telecom and Internet numbering and addressing schemes shall be supported as public identities. IP multimedia 
communication establishment (both originating and terminating) depending on originator shall be able to be based on 
E.164/tel URI (see RFC 3966 [5]) or SIP URI (see RFC 3261[6]). It shall be possible to assign several public identities 
for one subscription. 

NOTE: Numbering and addressing schemes other than E. 164/tel URI or SIP URI are not precluded from later 
releases. 

Public identities shall be administered by the network operator and shall not be changeable by the user. 

The network operator shall guarantee the authenticity of a public identity presented for an incoming session to a user 
where the communication is wholly across trusted network. This is equivalent to the situation for CLIP with today's 
telephony networks. 

The IMS is not required to support the generation of overlap signalling. Interworking Requirements (as in 
clause E.4. 10.1) require options for conversion. 

It shall be possible for a service to identify and interact with a specific UE even when multiple UEs share the same 
single Public User Identity. A UE shall be capable to identify and interact with a specific UE even when multiple UEs 
share the same single public user identity, except when the UE supports only limited capabilities and thus is unable to 
become engaged in a service that requires such functionality. Examples include a telemetry-only capable UE that only 
supports the capabilities for point-to-point communication. 

E.4.6 Void 

E.4.7 Regulatory service requirements 

See TS 122 101 [14] and TS 122 228 [9]. 

E.4.7. 1 Lawful Intercept 

The capabilities to support Lawful Intercept shall be as described in TS 187 005 [17]. 

E.4.7. 2 Emergency service 

The capabilities to support the Emergency Service shall be as described in TS 102 424 [3]. 

E.4.7. 3 Identifying malicious communications 

The IMS shall support the capability for a user to identify a communication as malicious. This service may be available 
to a user only after subscription. Once the user has indicated to the network that the communication is malicious, the 
IMS shall register at least the following information: 

• Terminating Identity Information; 

• Originator Identity Information; 

• Local Time and Date of the invocation in the network serving the terminating entity; 

The information shall not be available to the terminating entity nor the originating entity. The information shall be 
under the control of the network operator. 
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The user may identify the communication as mahcious during the alerting phase, during an ongoing communication, or 
for a Hmited period after the communication has ceased. 

E.4.7.4 Anonymous communications rejection 

A session is considered anonymous when a user receiving an incoming session cannot identify the originator. 

Anonymous communications rejection provides the capabiHty for network, on behalf of the user, to reject incoming 
sessions from users who have restricted the presentation of their originating identity. 

The IMS shall support the capability to be able to reject all terminating sessions when the originating entity cannot be 
identified, i.e. the asserted originating identity is marked "presentation restricted" or "presentation restricted by 
network" . 

E.4.8 Void 
E.4.9 Void 
E.4.10 Interworking 

SeeTS 122 228, clause 8 [9]. 

E. 4.1 0.1 Interworking witin legacy PSTN/ISDN 

The IMS shall support interworking with the legacy PSTN/ISDN network. 

The IMS interworking with the legacy PSTN/ISDN network shall not impact the IMS subsystem or the PSTN/ISDN 
network. The IMS network shall support the capability for limited interoperability with an existing PSDN/ISDN. 

The IMS shall support the interoperability of PSTN/ISDN like services with PSTN/ISDN Supplementary Services and 
vice versa. The scope of this interworking may result in a limited service capability. 

E.4.10. 1.1 Overlap Signalling 

Support for overlap signalling in the IMS is as an operator option limited to the interworking with legacy PSTN/ISDN 
networks that use overlap signalling. 

IMS Networks that interconnect to legacy PSTN/ISDN networks that do not implement overlap signalling are not 
required to support the feature. 

For these requirements, PSTN/ISDN networks that convert overlap signalling (received from other PSTN/ISDN 
networks) to en-bloc, are considered to be a network that does not support overlap signalling. 

The IMS shall interoperate to legacy PSTN/ISDN networks that supply overlap signalling. The following requirements 
shall be taken into account: 

• Conversion of overlap signalling to en-bloc shall take place within the IMS domain (without change to the 
legacy PSTN/ISDN). 

• Impact on the IMS shall be minimized. 

• A network option shall be provided to enable conversion to be performed using either: 

a simple solution (digit counting, simple look-up, or end-of-digit timer, etc.); 

complete solution - which shall minimize the post-dialling delay (may require an iterative look-up 
solution). 

NOTE: Overlap signalling support should not be linked to E. 164 numbering schemes. 
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The IMS is not required to support the generation of overlap signalling. 

The IMS is not required to support overlap signalling from terminals and customer networks. 

E. 4.1 0.2 Interworking with PSTN/ISDN emulation 

The IMS shall support interworking with the PSTN/ISDN Emulation subsystem. 

The IMS shall support the capability for limited interoperability with an emulation subsystem. 

The IMS shall provide at least the same level of interoperability with an emulation subsystem as achieved with legacy 
PSTN/ISDN networks. 

Support for overlap signalling between the IMS and PSTN/ISDN Emulation is dependent on the network options for 
conversion. 

E.4.10.3 Interworking with PLMN 

E.4.1 0.3.1 Interworking with IMS based PLMN 

The IMS shall interwork with an IMS based PLMN without impacting either the IMS or the IMS-based PLMN. 

E.4.1 0.3.2 Interworking with PLMN - CS Domain 

The IMS networks shall provide interfaces to PLMN - CS Domain networks. 

The IMS shall support interworking with the PLMN - CS Domain network. 

The IMS interworking with the legacy PLMN - CS Domain network shall not impact the IMS subsystem or the 
PLMN - CS Domain network. The IMS network shall support the capability for limited interoperability with an existing 
PLMN - CS Domain. 

The IMS shall support the interoperability of PSTN/ISDN like services with PSTN/ISDN Supplementary Services and 
vice versa. The scope of this interworking may result in a limited service capability. 

A mechanism shall be available in the network to provide information, if the PSTN/ISDN resources are not available. 

E.4.1 0.4 Interworking with packet cable network 

The IMS shall support interworking with Packet Cable networks. 

The IMS interworking with the Packet Cable network shall not impact the IMS subsystem or the Packet Cable network. 
The IMS network shall support the capability for limited interoperability with an existing Packet Cable Network. 

E.4.1 0.5 Interworking with other IMS network 

A TISPAN -compliant IMS shall interwork with other IMS based networks without impacting the TISPAN IMS. 

E.4.1 0.6 Interworking with other networks 

The IMS shall support interworking with non-IMS and non-TDM multimedia networks. The interworking with 
non-IMS and non-TDM multimedia networks shall not impact the IMS. 

E.4.11 Void 



E.4.12 Security Requirements 

See TS 122 101, clause 20 [14]. 
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E. 4.1 2.1 General 



The IMS shall provide sufficient security services and mechanisms to meet the service requirements given in the 
proceeding clauses. The security threat & risk analysis gives the rationale for qualifying what is to be understood as 
"sufficient security". 

The IMS subsystem shall provide services, including connectivity, to a user entitled to use the resources of the IMS and 
the IMS subsystem. 

However, to facilitate the early deployment of NGN, two special legacy scenarios, permit the verification to be linked. 
These two special deployment scenarios are: 

a) IMS authentication is linked to access line authentication (no nomadism). 

b) IMS authentication is linked to access authentication for IP Connectivity (limited nomadism can be provided). 
Both scenarios A and B shall allow UEs to perform access independent authentication to the IMS. 

E. 4.1 2.2 IMS security 

Detailed Security Requirements shall be as contained in TS 187 001 [7]. 

E.4.12.3 Network domain security 

The detailed requirements for network domain security are contained in TS 187 001 [7]. 



E.4.13 Charging and accounting 



Charging and accounting in IMS will be based on the collection of information from appropriate entities in the form of 
Charging Data Records (CDRs). The requirements for charging and accounting shall be as contained in TS 122 1 15 [8]. 

In addition to off-line charging, also on-line charging requirements are applicable. 
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Annex F (informative): 

Release 8 parts of Common IIVIS 



This annex contains candidate text to be removed from the document and submitted as company contributions to 3GPP 
as requirements to Release 8. There may be also suggestions what needs to be changed if not all text of a clause cannot 
be contributed as such to 3GPP. 



F.1 Void 

F.2 Void 

F.3 Void 

F.4 Capabilities for the support of IP Multimedia Services 

This clause covers the requirements of the IP Multimedia services to be supported by the 3GPP IMS 
(TS 122 228 [9] Release 8). 

F.4.1 Void 

F.4.2 Void 

F.4.3 Service requirements 

F.4.3.1 Void 

F.4. 3. 2 Handling of sessions 

F.4. 3. 2.1 Handling of session establishment 

F.4.3.2.1.1 Void 

F.4.3.2.1.2 Void 

F.4.3.2.1.3 Void 

F.4. 3. 2.1 .4 Presentation of multimedia information 

As network option, presentation of multimedia information services may be provided. In this case: 

• The network shall support the capabilities to present customized multimedia information to the originating and 
terminating parties (as in clause F.4.3.1 1.1). 

• The network shall support the capabilities to suppress the presentation of customized multimedia information 
when requested by the originating or terminating party (as in clause F.4.3.1 1.2). 
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F.4.3.2.2 Void 

F.4.3.2.3 Void 

F.4.3.2.4 Void 

F.4.3.2.5 Void 

F.4.3.2.6 Void 

F.4.3.2.7 Void 
F.4.3.3 Location Service 

The IMS location service shall provide a mechanism that may offer network asserted location information to 
applications. The provision of location information to applications shall depend on policies and user preferences. 

The network asserted location mechanism shall identify the physical access through which user connectivity is granted. 

The network asserted location mechanism shall locate individual users that have authenticated with the access network. 

The IMS access network shall provide location information to the IMS. Location information provided by the IMS 
access network to the IMS shall include network asserted location information. 

The actual location information may take various forms (e.g. network location, geographical coordinates, post mail 
address, etc.), depending on agreements between the access and IMS providers and on user preferences regarding the 
requested privacy of their location. 

The network may be provided with a terminal equipment location information. 

F.4.3.4 Void 
F.4.3.5 Void 



F.4.3.6 Subaddressing (SUB) 



Where public telecommunication numbers are used, the NGN may support the Subaddressing (SUB) service that allows 
the called (served) user to expand his addressing capacity beyond the one given by the public telecommunication 
number. See also ETS 300 059 [24]. 

NOTE: Subaddressing is needed for interoperability with legacy users. Subaddressing is needed when services for 

at least one of the users are provided from either a legacy ISDN network or PSTN/ISDN Emulation. The 
IMS itself does not support a Subaddressing service, but supports mechanisms for the use of Subaddresses 
as an integral part of IMS. 

The NGN may support the interoperability of Subaddressing with the PSTN/ISDN and vice versa. 



F.4.3.7 User-to-User Signalling (UUS) 



The NGN may support the User-to-User Signalling (UUS) service that enables a calling party to send and/or receive a 
limited amount of User-to-User-Information (UUI) to/from a called party in association with a communication. See also 
ETS 300 284 [25]. 

NOTE: UUS is needed for interoperability with legacy users. UUS is needed when services for at least one of the 

users are provided from either a legacy ISDN network or PSTN/ISDN Emulation. 

The NGN may support the interoperability of User-to-User Signalling services with the PSTN/ISDN and vice versa. 
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Only UUS service 1 with an implicit request is supported. 

F.4.3.8 Customized multimedia information services 
F.4.3.8.1 Customized multimedia information presentation service 

The customized multimedia information services (COMIP/CTMIP and COMIF/CTMIF) are studied in 
TR 181 015 [26]. 

Multimedia information presentation service is able to present multimedia information: 

• to the terminating party. This service is the Customized Originating Multimedia Information Presentation 
service (COMIP); 

• to the originating party. This service is the Customized Terminating Multimedia Information Presentation 
service (CTMIP). 

The network shall provide the capability for the user (both the originating and terminating party) to: 

• Receive multimedia information provided by the network or via service platform during the communication 
establishment. 

• Replace the default alerting and ringing tone by respectively the multimedia information of CTMIP and the 
multimedia information of COMIP. 

• Send multimedia information to the other party via service platform or send the multimedia information per 
call basis instantaneously. 

• Choose multimedia information presented to her/his during communication establishment between information 
provided by her/himself or information provided by another party. By default, multimedia information 
provided by her/himself is the one to be presented to her/himself. 

• Distinguish information provided via service platform and information provided by the network. 

• Allow the subscriber and/or the service provider to customize his/her multimedia information presentation 
based on several rules (according to party identity, anonymous, external list, validity, media, presence status, 
etc). If the user has activated the service but there is no customized multimedia information provided or he/she 
has chosen the default alerting or ringing tone, then the service shall fall back to the normal network 
behaviour. 

• Dynamically select the content of the COMIP/CTMIP services taking into account information available in the 
network, e.g. originating and/or terminating party's location and/or presence information. 

• Send an indication to the multimedia information presentation service which multimedia information to play to 
the other party (e.g. when the terminating party is notified about an incoming communication, the terminating 
party can send an indication to the CTMIP service which CTMIP to play to the originating party). 

• Receive at least certified information of this other party (e.g. the other party's identity or other). 
The network may also provide the capabilities for the user (both the originating and terminating party): 

• In case of the user who receives multimedia information, to be enabled to copy the multimedia information if 
permitted (by taking in account DRM issues). 

• To stop multimedia information presentation service when it is playing. If the originating or the terminating 
party has stopped the CTMIP, this one is replaced by the default alerting tone. If the terminating or the 
originating party has stopped the COMIP, this one is replaced by the default ringing tone. 

• To replace multimedia information by other multimedia information when it is playing. 

• To continue to receive multimedia information presentation services after communication establishment. 
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F.4.3.8.2 Customized multimedia information filtering service 

Customized Multimedia information filtering service shall allow the user to filter multimedia information: 

• If the user is the terminating party, this service is the Customized Originating Multimedia Information 
Filtering service (COMIF). 

• If the user is the originating party, this service is the Customized Terminating Multimedia Information 
Filtering service (CTMIF). 

The network should provide the capability for the user who receives multimedia information (both the originating and 
terminating party) to reject during communication establishment presentation of multimedia information provided by 
another party according to some rules: 

• Reject all multimedia information presentation, unconditionally. 

• Reject multimedia information presentation for unknown parties and accept all known parties. 

• Reject multimedia information presentation for parties identified as with malicious information in a black list 
and accept all others. 

• Request the user if he/she wants to reject multimedia information only for unknown parties and accept 
multimedia information presentation all others (default). 

• Request the user what to do each time (e.g. to present multimedia information, to reject the multimedia 
information, etc.). 

F.4.4 Void 

F.4.5 Void 

F.4.6 Void 

F.4.7 Void 

F.4.8 Void 

F.4.9 Void 

F.4.10 Void 

F.4.11 Void 

F.4.12 Void 

F.4.13 Charging and accounting 

SeeTS 122 115 [8]. 
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As a new feature, the real-time transfer of tariff information in interworking scenarios shall be supported in TISPAN, in 
order to support value added services that are billed by the caller's operator, e.g. Premium rate services (0900) or 
hotlines. Such services often appear as 3"^ party services where the tariff information resides in the called network and 
the caller's operator does not have this information. 

This tariff information must be submitted by the external provider in realtime, so that the caller's operator is capable: 

• providing Advice of Charge ( AoC) information to the caller; 

• recording the imported tariff information. 

The transferred tariff information is not used for actual charging. 
The following interworking scenarios must support this feature: 

• Interworking between two TISPAN NGNs. 

• Interworking between a TISPAN IMS and PSTN/ISDN. 

• Interworking between a TISPAN IMS and a PES. 

NOTE: In order to support offline charging for third party services where the tariff information resides in the 
called network and the caller's operator needs to bill the end user for that service, the service-hosting 
network needs to provide appropriate charging information to the caller's operator in a secure way, 
independently from the realtime transfer of charging information for AoC purposes. 

For the Interconnection scenarios, the following charging requirements are applicable: 

1) All the charging and accounting information shall be collected as closest as possible to the interconnection 
point. 

2) A session or a service instance shall be uniquely identified within a network domain to allow a correct 
accounting and charging. 

3) The identities of the originating network and of the destination network shall be unique and transported at 
signalling layer. 
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